Columbia Kermit/kermit.zip/newsgroups/misc.19951130-19960209/[e-mail]_Thu Dec 14 16:13:41 1995.msg

Internet Message Format | 2020-01-01 | 9KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17610
  (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun>); Thu, 14 Dec 1995 11:13:49 -0500
Received: (from news@localhost) by apakabar.cc.columbia.edu (8.6.12/8.6.12) id LAA20097 for kermit.misc@watsun; Thu, 14 Dec 1995 11:13:47 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: problems with packets bigger than 94 bytes
Date: 14 Dec 1995 16:13:41 GMT
Organization: Columbia University
Lines: 185
Message-Id: <4apifl$[e-mail]>
References: <4ahd39$[e-mail]>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: [e-mail]

In article <4ahd39$[e-mail]>,
Matthias Noethe <[e-mail]> wrote:
>Hi everyone,
>
>I'm trying to send large text files, sometimes binaries from a linux
>machine to a vms host. I try to use sliding windows but when I transmit
>larger packets than 94 bytes I only get naks from the vms-host.
>So far I use 31 windows.
>Buffers are big enough 100000 !
>
>Any suggestions ...
>
You should read the "Using C-Kermit" chapter that explains the relationship
of packet length and window size to performance.  By the way, "Using
C-Kermit" is available in German too:

    Frank da Cruz and Christine M. Gianone, "C-Kermit - Einfuehrung und
    Referenz", Verlag Heinz Heise, Hannover, Germany (1994).
    ISBN 3-88229-023-4.  Deutsch von Gisbert W. Selke.  Price: DM 88,00.
    Verlag Heinz Heise GmbH & Co. KG, Helstorfer Strasse 7, D-30625 Hannover.
    Tel. [phone], Fax. [phone].

Also, pay particular attention to flow control.  It is all explained in the
manual.

I would also ask you to read the CKVINS.DOC file that comes with VMS C-Kermit.
As you will see, C-Kermit's buffers are not the only ones you need to be
concerned with.  VMS itself has some buffering limitations that can only be
changed by the system manager, either through privileged commands or by
reconfiguring the system.

In the meantime, I would suggest that you reduce the window size to something
reasonable, like 2 or 4, and then you should be able to increase the packet
length.

Here, for reference is an earlier discussion of Kermit file transfer
performance on VMS:

In article <3en6v1$[e-mail]>,
Michael Donohue <[e-mail]> wrote:
>AN earlier post said that Kermit was not entirely bad for transfering
>files.  I tried and tried, but the max cps I could get was 157 or so on a
>9600 bps line.
>
>Could someone please tell me ... the settings for kermit?
>
I have posted the following message to this group several times -- if
there is an FAQ, I hope this can be added to it.  But first, a word from
our sponsor.  The current version of Kermit for VMS is C-Kermit 5A(190).
It supersedes all previous VMS Kermit releases and programs, including all
versions of Kermit-32, which is no longer supported.  You can get C-Kermit
5A(190) by mail order from Columbia University, or by anonymous ftp to
kermit.columbia.edu, directory kermit/f, file ckvaaaa.hlp, read it, go
from there.  You can also access the Kermit repository via the Web at URL:

  http://www.columbia.edu/kermit/

The Kermit software effort is funded primarily by mail order and book
sales.  Users of C-Kermit (and MS-DOS Kermit) are encouraged to purchase
the appropriate manual -- it will show you how to use the software and how
to get the most out of it (e.g. answering questions like the one above, so
they need not be posted to dozens of newsgroups over and over and over
again).

If you type "help" at the C-Kermit> or MS-Kermit> prompt, you should get
(among other things) a complete reference to the appropriate manual.  If
you want more information, access the Web site listed above or send e-mail
to kermit.columbia.edu.

The following message is almost a year old and discusses the previous
release of C-Kermit, but aside from that, it still applies.

In article <s5$[e-mail]>
[e-mail] (Gregory Perron) writes:
>
> I'm downloading from a vax 4000-90 thru a terminal server of some sort
> to my PC.  14.4's at both ends: I have a cardinal internal; they have
> us robotics.  I get messages of 14.4, lapm, v.42bis, etc.  But,
> downloads have been hideous.
>
> I've given up on sz, because of too many aborted transfers.  I
> *think* the problem is w/ the vax, but I'm not sure.  [I get flawless
> 1600-1650 cps dl's on zipped files from a local bbs] Yes, I tried all
> the -ebrw permutations I could think of.
>
> On to kermit: I use procomm plus/dos 2.01 on my PC.  On the vax,
> ckermit pops up and says:
> Ckermit 5a(188) 23 NOV 92, OpenVMS Vax.
>
You'll get better results with C-Kermit 5A(189) or later, which has two
new features described below.  C-Kermit 5A(189) is available via
anonymous ftp to kermit.columbia.edu, directory kermit/b, get the file
ckvaaa.hlp, read it, take it from there.

> My ckermit.ini file has:
> set send pack 1000
>
This command is not needed; see the documentation.

> set receive pack 1000
> set buff 20000 20000
> set file type bin
> set windows 10
> set block 3
>
> Symptoms: max dl cps has been around 1100 for a zipped/jpg/gif file.
> And that's unusual: 950-1050 is more normal. It's almost like I'm
> only at 9600, modem report aside.
>
I can't speak for Procomm, but I ran some tests using MS-DOS Kermit 3.13
(the current version) on a 486/66 over a V.32bis/V.42/V.42bis dialup
connection to a Cisco terminal server, and from there to a VAXstation
3100 running VMS 5.x and C-Kermit 5A. The calling modem is a Telebit
T3000, the answering modem is a USR Courier.

MS-DOS Kermit 3.13 is available via anonymous ftp to kermit.columbia.edu,
directory kermit/bin, binary mode, file msvibm.zip.

In these tests, I downloaded a 330K ZIP file (MSVIBM.ZIP -- the MS-DOS
Kermit 3.13 distribution).  My serial interface speed was 57600 bps, and
I used RTS/CTS flow control between my PC and the modem, and RTS/CTS was
also active between the answering modem and the terminal server.

In the first test (10 window slots x 1000-byte packets, same settings as
yours), I achieved an effective throughput of 1091 cps, like you got.

Since the connection between the terminal server and VMS is via TCP/IP
TELNET, and we know that TCP and IP will handle the flow control between
the VAX and the terminal server, I told C-Kermit to SET FLOW NONE (its
default setting is XON/XOFF) and ran the test again: 1136 cps.

Now that we've got the basics taken care of, we can work on tuning.
Next I tell C-Kermit to:

  SET CONTROL UNPREFIX ALL
  SET CONTROL PREFIX 1 129 255

(version 5A(189) or later is required for this; see the CKCKER.UPD file
for explanation) -- This removes control-character prefixing overhead
for all but 3 characters (4 really: NUL, Ctrl-A, Ctrl-A plus parity, and
the TELNET IAC character).  Now I get 1549 cps.  Note: control-character
unprefixing is of benefit primarily for precompressed files, secondarily
for uncompressed binaries, and has very little effect at all on text
files.

Well, the PC I was using is one of the new "high-speed, low-cost"
models, and so lacks a buffered UART.  All of the above transfers
suffered various amounts of retransmissions due to UART buffer overruns.
Switching to a much slower PC (a PS/2-70, 15MHz I think) that has a
16550A buffered UART, same transfer, same parameters, the throughput
goes up to 1601 cps.

Now, since I don't have to worry about buffer overruns any more, I
increase Kermit's packet length to 5000 (SET RECEIVE PACKET-LENGTH
5000).  Throughput: 1608 cps.

And now, since this is a precompressed file, I note that neither
Kermit's run-length compression, nor the modem's V.42bis compression
will do any good -- and some would say that they slow things down
a lot.  Let's see.  I turn both off:

  Kermit: SET REPEAT COUNTS OFF (C-Kermit 5A(189) or later required).
  Modem:  ATS190=0 (Telebit T3000)

and download the file again.  Result: 1616 cps.  Not a big difference.

Lessons (which apply mainly to this particular type of connection):

 1. Buffered UARTs are better than nonbuffered UARTs.
 2. Be sure to get the flow control at both ends.
 3. Use long packets (1K - 5K, whatever works) and sliding windows
    (4 or more).
 4. Once you've got all that working optimally, you can squeeze out
    another 20-30% efficiency with control-character unprefixing.
 5. After that, don't bother too much with fine tuning, particularly
    with disabling modem or software compression - it makes very little
    difference.

Please, before we have another flurry of postings from people asking
for the "optimal" list of control characters to be unprefixed, THERE IS
NONE.  Every connection is different, with its own unique characteristics.
Read the documentation.  Ditto for all the other variables we have looked
at here: window size, packet length, flow control, etc.

- Frank